Traditional broadcast systems typically deliver media information in a one-way fashion, from a source module to a target module. The target module typically comprises a conventional television set or one-way set-top box, which may receive analog or digital signaling. As such, the communication channel that couples the source module to the target module typically does not provide any mechanism for allowing the target module to alert the source module when it has failed to receive one or more parts of the media information. This does not present many difficulties, however, as the communication channel in traditional systems typically uses analog delivery (in which small amounts of missing information may not appreciably degrade the quality of the presentation) and/or proprietary infrastructure (which is typically designed to deliver the media information in a reliable manner).
Systems which use public networks to transmit information do not afford the same level of reliability, and, as such, commonly include mechanisms for addressing problems that are encountered in sending information from a source module to a target module. For instance, public WAN networks commonly use the Transmission Control Protocol (TCP) to ensure the reliable delivery of information from a source module to a target module (where the target module typically comprises some type of computer device coupled to the public network). This protocol sends information to the target module in chunks. The target module, upon successful receipt of information, sends an acknowledgement message back to the source module, providing information regarding the last portion of the information that it has successfully received, and a window size specifying how much more information the sender may send beyond the last acknowledged information. If the source module does not receive the acknowledgement message in a predetermined time, then it will assume that the information has been lost. The source module will then retransmit the information to the target module. The TCP protocol will dynamically change the size of the window to match the prevailing conditions in the public network, increasing the amount of information specified by the window when conditions are assessed as good (that is, as favoring reliable communication).
The above strategy works well for the transmission of non-time-critical information (such as E-mail messages and web pages), but does not provide a suitable solution for the streaming of media information. Namely, in streaming applications, the target module must receive a continuous stream of media information according to a defined demand schedule; if it does not, the target module's decoder will consume information with “holes” in it before the network has an opportunity to fill in such holes. This will lead to various artifacts in the media playback, or, in extreme cases, can lead to the stream being completely disabled (e.g., “dropped”). This type of shortcoming does not suggest a flaw in TCP, however, as this protocol was designed to deliver information over a public network in a manner that is fair to multiple competing applications that happen to be active at the same time; it was not designed to ensure that a particular target module is always supplied with a minimum amount of streaming media information. Generally, the loss of information in a digital stream is often more distracting to a user than the loss of information in traditional analog delivery, as such loss can manifest itself in abrupt interruptions in the presentation in which the presentation is entirely disabled during the interruptions.
Therefore, practitioners in the art often resort to other techniques to ensure the reliable delivery of media information over networks. FIG. 1 illustrates one exemplary solution envisioned by the present inventors. As indicated in this system 100, a source module 102 sends a stream of media information 104 over a communication channel 108 to a target module 108. In this solution, the target module 108 determines whether it has received each packet in the stream of media information 104. The target module 108 may “miss” a packet because the packet has been lost during transit or because the packet has been received but it has been corrupted (and is therefore unusable). If the target module 108 determines that it has missed a packet, it can immediately send a retry message 110 to the source module 102. The retry message asks the source module 102 to supply the missing packet. The source module 102 honors this request (if it can) by sending the missing packet to the target module 108.
This solution does not provide satisfactory results in all circumstances. Due to the nature of packet-based networks, packets are not guaranteed to be received by the target module 108 in order. As such, a missing packet may not have been entirely lost, but may be simply delayed in reaching the target module 108. As such, it may happen that the target module 108 sends a retry request 110 for a packet that arrives shortly thereafter. In another case, the target module 108 may come to the conclusion that a prior retry request has been lost when it does not receive a response to the retry request from the source module 102. But the source module 102 may indeed have received this prior retry request and is in the process of responding to it. Both scenarios may result in the target module 108 receiving duplicate packets in the stream of media information 104.
This problem may not seem of great concern for the isolated scenarios described above. But in certain circumstances, the unnecessary transmission of packets in the system 100 can escalate to a phenomenon known as a packet storm. This scenario plays out as follows. The target module 108 may determine that many packets are missing, upon which it issues a corresponding number of retry requests to the source module 102. The source module 102 then provides the missing packets to the target module 108. However, many communication channels 106 have prescribed limitations on the amount of bandwidth devoted to handling communication between the source module 102 and the target module 108; this allotted bandwidth must handle both the stream 104 and the retry requests 110, as well as the transmission of retry packets from the source module 102 to the target module 108 in response to the retry requests 110. It may happen that the transmission of retry packets from the source module 102 to the target module 108 begins to overburden the capacity of the communication channel 106. Forcing too much information through the communication channel, in turn, will result in the potential loss of more packets in the stream 104. These missed packets, in turn, can lead to additional retry requests, additional retry packets, further consumption of bandwidth resources, and the loss of yet more packets. It can be seen that this phenomenon (the packet storm) describes a deleterious feedback loop that can lead to very poor performance, and possibly the complete disablement of the stream 104. As appreciated by the present inventors, key to the source of this problem is the transmission of redundant (or otherwise inappropriate) retry requests from the target module 108 to the source module 102, and the transmission of redundant (or otherwise inappropriate) retry packets from the source module 102 to the target module 108.
For at least the above-identified exemplary reasons, there is a need for more effective and efficient strategies for streaming media information from a source module to a target module.